
			    MEX Newsletter #003

Date:	  05-27-84       From:  Ron Fowler               MEX rev:  1.00


                            New Patch File
                       Correspondence Information
                         Hi-Speed File Transfers
                           Upcoming Release
                             MEX Overlays
                      Jury Still Out on Dial-Abort


This is the third in a series of (hopefully) informative notes for users of
the MEX communications program.  These newsletters will provide bug fixes,
tips, applications information, etc.

------------------------------------------------------------

New patch file

Many of you have probably noticed how sluggish MEX is during file transfers,
often taking 30 or 40 seconds just to get started (also very noticeable dur-
ing batch transfers).  Well, it seems the timing constants in MEX are a off
by a factor of three!  The following HEX file patch will repair that, and
bring your revision level up to 'C' (no, I didn't skip B -- it just didn't
get distributed very far).

This patch also repairs a bug that several overlay writers have reported:
after implementing the NEWBDV overlay extension, numbers entered on the
command line (ie, not called from the phone library) would cause a random
baud rate to be set.

Incidently, this patch repeats the A patch in Newsletter #002 -- if you
haven't already installed that one, you don't have to worry about installing
it first.  If you have installed it, this one just writes over the same
code that the first one generated, so it won't hurt anything.


Here's the patch code:

:0B0CF5003EFF323853215C53C3FF1256
:100E6A00CDB314D83E0CEBCD0146EBC3DE123AD417
:0F0E7A0052B7C4EA31F1F5E67F21DC52C3894358
:0152D40000D9
:0312DA00C36A0ED6
:03438100C3780EF0
:010ED70043D7
:01130C0000E0
:0312FC00C3F50C2B
:020EA600D0007A
:020EAF000D0034
:0000000000


Just 'clip' the above lines from this file with your text editor into
a file named MEXFIX.HEX, and do this:

		MLOAD MEX.COM=MEX.COM,MEXFIX

(make sure you've saved a copy of MEX before making the patch, however,
in case something goes wrong).

I've been using the timing patch for the last week or so, and it makes MEX a
lot more responsive, but since it changes the overall timing for the entire
program, there is always the possibility of a side-effect.  If this patch
causes any weird problems (a symptom of such a side-effect would be something
that happens three times as fast as it should), please let me know.

One final note: since the patch area within MEX was entirely consumed by
previous patches, this one had to go at the top of the overlay area.  This
shouldn't be a problem, unless you use an overlay that uses every available
byte, something I think is pretty unlikely (if you're using the standard MXO
Smartmodem overlay, the top area is definitely free).

------------------------------------------------------------

Correspondence:

The Fort Atkinson BBS is back online 24 hrs (except when in use locally)
at 300 and 1200 baud.  This is now the best way of reaching me with a question
or comment (outside of Arpanet); since my Compuserve access is through another
user's account, I log in on CIS as seldom as possible (it's also a long
distance call).  I've also been logging in a lot less frequently on the SYSOP
system in Michigan ... (it's always busy!).

Our overlay collection is less than complete (even some of the new MXO over-
lays are not present there yet).  We hope to have a complete collection on-
line by early June, of both MXO and M7 overlays.

Fort Fone File Folder: (414) 563-9932 ... should answer on 1st ring (made
                       busy when in use locally)


------------------------------------------------------------

High-speed transfers:

I've been using MEX locally for transfers between two computers connected
through an RS-232 link.  File transfers at speeds of 9600 and 19200 are
possible, with the following guidelines noted:

1) If one computer has a faster CPU clock speed than the other, it can receive
   at 9600 or 19200 without problems (assuming no extraordinary delay in 
   the overlay modem I/O routines).

2) The receiver should use the 'Q' mode ('quiet': no status messages, but more
   relevantly, no console-status checking) if the transmitter is at an equal or
   greater clock speed.

3) It's not generally a good idea to view either received or transmitted
   characters at the receiving end, regardless of clock speed (i.e., avoid use
   of the V, S and R secondary commands at the receiving end).

4) Batch file transfers will work much better with the above speed patch.


------------------------------------------------------------

Forthcoming release:

I hope to start work on MEX revision 1.10 within the next week or so (pend-
ing completion of a couple of deadlined projects I'm involved in).  The new
release will hopefully accomplish the following:

	- Incorporate all patch fixes
	- Fix a couple of minor annoyances (like control-C abort not
          working at times)
	- Add some hooks requested by users for special overlay access
	- Add a couple of features 

If I can get to it, the new release should be out sometime in the first
half of June (unless I get carried away adding stuff).

------------------------------------------------------------

MEX overlays

MEX overlays are coming in at an astonishing rate; turns out there is some
confusion about just where a MEX overlay differs from an M7 overlay, so
I thought I'd clarify that a little.

MEX overlays do not call the MDM7 jump table (the one with JMP$ILPRT,
JMP$INLNCOMP, etc) .... instead, they use the MEX service processor.  The
reason for this is facilitate my long-term plan to condense the overlay
format (say around MEX 2.0, perhaps).  I should be able to take an MXO
overlay and turn it into an MX2 overlay in a matter of minutes, with
little chance of buggifying the code in the process.

In addition, I'd prefer that MXO overlays use the simpler label names
I've employed in the PM and GB overlays (although I should have mentioned
this much sooner: quite a number of re-released M7 overlays have the old
label names intact).

At any rate, the idea is that if I impose a new overlay structure in the
future, the burden of changing the overlays should fall on me, not the
user (*especially* if MEX2 is a commercial product, something I'm still
fighting with myself about); the MXO format makes that change somewhat
easier.

------------------

Dial-abort problem:

A lot of people have mentioned that they can't abort an in-progress DIAL
command.  I haven't been able to duplicate that here (abort always works
fine for me).  If anyone has any idea what's causing this problem, please
let me know.

There are a number of places within MEX that don't check the console for
an abort (mostly within file transfers); also some screen displays that
don't check for a ^S pause.  Hopefully, I'll zap all these when I do the
new release ....


------------------

Special thanks here to Cliff Harrison for re-formatting the DOC files;
they were pretty ugly in their original state (I rushed them out in about
a day or 2).  The new format is a welcome change; I'll make sure they
stay maintained this way.

----------------------------< MEXNEWS.003 >------------------------------
